CVSS 3.1 - Common Vulnerability Scoring System 3.1
This section will cover the Common Vulnerability Scoring System (CVSS) 3.1.
Table of Contents
- Overview
- Base Metric Group
- Exploitability Metrics
- Attack Vector (AV)
- Attack Complexity (AC)
- Privileges Required (PR)
- User Interaction (UI)
- Scope (S)
- Impact Metrics
- Confidentiality (C)
- Integrity (I)
- Availability (A)
- Exploitability Metrics
Overview
CVSS is used to calculate the severity of vulnerabilities. It is based on five main factors:
- Damage Potential
- Reproducibility
- Exploitability
- Affected Users
- Discoverability
The CVSS system helps categorise the risk associated with a finding or vulnerability. This helps organisations prioritise issues based on the rating.
The CVSS scoring consists of three main metrics:
- Base Metric Group
- Temporal Metric Group
- Environmental Metric Group
The main metrics that will be used will be the base metric group. The base metrics group consists of three categories.
| Metrics | Contents |
|---|---|
| Exploitability Metrics | Attack Vector (AV), Attack Complexity (AC), Privilege Required (PR), and User Interaction (UI). |
| Impact Metrics | Confidentiality (C), Integrity (I), and Availability (A). |
| Scope | Scope (S) |
From the above table, we can see the metrics in the base group with scope being its own.
Basic Metric Group
The base metrics group represents the vulnerability characteristics and consists of exploitability metrics and impact metrices.
Exploitability Metrics
The exploitability metrics are a way to evaluate the technical means needed to exploit the finding or vulnerability.
The below tables will list the options and their description for the respective metrics.
Attack Vector (AV)
There are four options - Network (N), Adjacent (A), Local (L), and Physical (P).
| Option | Description |
|---|---|
| Network (N) | The vulnerable component is bound to the network stack, it is accessible via the internet, different networks, etc. |
| Adjacent (A) | The vulnerable component can only be accessed when the attacker is in the same network subnet, etc. |
| Local (L) | The vulnerable component is not bound to the network and the attacker path is via read/write/execute capabilities. Some examples are accessing the target system locally such as using the keyboard, console, out-of-bands means, remotely using SSH, or relies on user interaction by another person to exploit the vulnerability such as social engineering. |
| Physical (P) | The vulnerable component requires the attacker to be able to touch or manipulate it. Examples of such are evil maid attack, cold boot attack, and etc. |
Note: When deciding between Network or Adjacent, if the attack can be launched over a wide area network (WAN), intranet, or from different subnets, use Network.
Attack Complexity (AC)
There are two options - High (H) and Low (L).
| Option | Description |
|---|---|
| High (H) | The attacker require specialised conditions that is beyond their control. The attack also requires a high amount of time and effort to be carried out. An example is where the attacker must gather knowledge about the environment such as configuration settings, sequence numbers, or shared secrets. The attacker must prepare the target environment to improve the exploit reliability. The attacker must inject themselves into the logical network path between the target and resource (e.g. man-in-the-middle (MiTM) attacks). |
| Low (L) | The attacker does not require specialised conditions. The exploit can be repeatable with a high success rate. |
Privileges Required (PR)
There are three options - High (H), Low (L), and None (N).
| Option | Description |
|---|---|
| High (H) | The attacker requires privileges that provides a significant control over the vulnerable component. An example will be requiring administrator privileges before exploitation can take place. |
| Low (L) | The attacker requires basic privileges. An example will be a regular user. |
| None (N) | No privileges are required to exploit the vulnerable component. |
Note: If items such as hard-coded credentials are found or requires social engineering, it will be scored as None.
User Interaction (UI)
There are two options - Required (R) and None (N).
| Option | Description |
|---|---|
| Required (R) | A successful exploitation requires the user to interact. For example, the user has to click a button before XSS can be successfully exploited. |
| None (N) | No interaction is required. An example will be zero-click exploits or SQL injection. |
Scope (S)
There are two options - Changed (C) and Unchanged (U).
| Option | Description |
|---|---|
| Changed (C) | An exploited vulnerability is able to affect resources beyond the security scope managed by the security authority of the component. |
| Unchanged (U) | An exploited vulnerability only affects resources managed by the same security authority. |
Note: A security authority is a mechanism (e.g., an application, operating system, firmware, sandbox environment).
Example of when to use Changed:
Consider a web application as a security authority and the items within it such as inputs, login pages, buttons, etc. within it as components.
If the component within the application affects another component within it, the scope is Unchanged. However, if those components starts affecting items outside the web application such as the operating system, user browser, etc., it will be scope changed.
An example will be Cross-Site Scripting (XSS) and text injection on an input box. If the exploit only affects the input box (the webpage) such as manipulating text on the webpage via text injection, the scope will be Unchanged.
However, if the attacker is able to affect resources outside the web application such as the cookies, stealing session data, user browser, or redirecting the user to a different page via XSS, it will be Changed.
The scope change occurs when the text injection becomes XSS where it goes from affecting only the webpage to the user browser.
This option has been removed in CVSS 4.0.
Impact Metrics
The impact metrics represents the repercussions of successfully exploiting the vulnerability. It is based on the CIA triad (Confidentiality, Integrity, and Availability).
Confidentiality (C)
There are three options - High (H), Low (L), and None (N).
| Option | Description |
|---|---|
| High (H) | There is a total loss of confidentiality. An attacker is able to access data that it is otherwise unauthorised to view. |
| Low (L) | There is a partial loss of confidentiality. An attacker is able to steal information but it is not sensitive/does not have a high impact or does not cause a direct, serious loss. |
| None (N) | There is no loss of confidentiality. The attacker is only able to access items that it is authorised to do so. |
Integrity (I)
There are three options - High (H), Low (L), and None (N).
| Option | Description |
|---|---|
| High (H) | There is a total loss of integrity. An example will be where an attacker is able to modify all entries in a database. The data is no longer "trustworthy". |
| Low (L) | There is a partial loss of integrity. An example will be where an attacker is able to partially modify some items but it is limited and does not have a direct, serious impact. The data is still somewhat "trustworthy". |
| None (N) | There is no loss of integrity. The attacker is unable to modify any information. The data can be "trusted". |
Availability (A)
There are three options - High (H), Low (L), and None (N).
| Option | Description |
|---|---|
| High (H) | There is a total loss of availability. An attacker is able to fully deny access to the resources to legitimate users. An example will be crashing a server or disabling user accounts. |
| Low (L) | There is a partial loss of availability. An example will be where there is performance loss but legitimate users are still able to access the resources. |
| None (N) | There is no loss of availability. Legitimate users are able to access the resources with no impact. |
References: